ci: Add tft plan and workflow #214
Conversation
spetrosi
force-pushed
the
ci-testingfarm-tests
branch
2 times, most recently
from
fff2842 to
35b995a
Compare
|
plans/README-plans.md states that there are going to be two machines: a controller node and a managed node. Previously, there was just one machine fulfilling both functions. And the single machine didn't have an address usable in the cluster configuration. So the role tests were set to use localhost as a node for the cluster in case If the intention is to separate the controller node and the managed node, this should be addressed in the tests. To be able to do that, the managed node needs to have a domain name which resolves to its IP address, so that these items can be used in the cluster configuration. |
vars/RedHat_10.yml
Outdated
| __ha_cluster_repos: | ||
| - id: rhel-9-for-{{ ansible_architecture }}-highavailability-rpms | ||
| name: High Availability | ||
| - id: rhel-9-for-{{ ansible_architecture }}-resilientstorage-rpms |
There was a problem hiding this comment.
Is 'rhel-9' in RHEL 10 config a mistake or a temporary solution? When to switch to rhel-10?
There was a problem hiding this comment.
Automation copied vars/RedHat_9.yml into vars/RedHat_10.yml. Can you check if repository for rhel 10 exists?
There was a problem hiding this comment.
Right now, rhel-10-for-x86_64-highavailability-beta-rpms and rhel-10-for-x86_64-resilientstorage-beta-rpms exist. I think the role must identify whether beta version is used by looking into /etc/redhat-release and set repos based on that. I'll do this in a separate PR.
There was a problem hiding this comment.
@richm does it make sense to support beta? Or we can hardcode GA values that will work with RHEL 10 ga?
There was a problem hiding this comment.
@richm does it make sense to support beta? Or we can hardcode GA values that will work with RHEL 10 ga?
Not sure. Whatever we do, it should work for
- tox ... -- --image-name rhel-10-beta
- tox ... -- --image-name rhel-10
and also for downstream testing. Note that in all of these cases, the image/managed node is already configured with the appropriate repos, so we need to ensure that the ha_cluster tasks that enable these repos are skipped.
spetrosi
force-pushed
the
ci-testingfarm-tests
branch
2 times, most recently
from
20779e3 to
34323fd
Compare
This change is for running tests in Testing Farm CI. This is a replacement for BaseOS CI that we are currently using. Running it Testing Farm gives us more control. It adds a workflow for running tests, and a plans directory containing a test plan and a README-plans.md with some info. Note that this workflow runs from the main branch. This means that changes to the workflow must be merged to main, then pull requests will be able to run it. This is because the workflow uses on: issue_comment context, this is a security measure recommended by GitHub. It saves us from leaking organization secrets. The functionality is WIP, so await future fixes and updates. Signed-off-by: Sergei Petrosian <[email protected]>
spetrosi
force-pushed
the
ci-testingfarm-tests
branch
from
34323fd to
da486b1
Compare
In the current (baseos ci) testing, there is a controller node and a managed node. The only difference is that in the testing farm implementation, the test explicitly provisions the controller node. In baseos ci, the controller node is "implicitly provisioned". However, one of our downstream test scenarios does use a single host for both, and runs with
The test should work in both of the above scenarios.
Ok, but the test should also run in the |
This change is for running tests in Testing Farm CI. This is a replacement for
BaseOS CI that we are currently using. Running it Testing Farm gives us more
control.
It adds a workflow for running tests, and a plans directory containing a test
plan and a README-plans.md with some info.
Note that this workflow runs from the main branch. This means that changes to
the workflow must be merged to main, then pull requests will be able to run it.
This is because the workflow uses on: issue_comment context, this is a security
measure recommended by GitHub. It saves us from leaking organization secrets.
The functionality is WIP, so await future fixes and updates.
Signed-off-by: Sergei Petrosian [email protected]